其他
回归单体成为潮流?腾讯文档如何实现灵活架构切换
The following article is from 腾讯云开发者 Author 安佳玮
高运行成本:每个微服务内部都要运行一套 tRPC-Go 框架运行时,它重复占用了大量的内存和 CPU 资源。而对私有化客户来说,他们的文档服务可能只有几十到几百人使用,这样的运行成本是不可接受的。 高部署成本:每个服务都需要维护 tad 描述文件。按照半年到一年的版本更新节奏,每次更新时,需要更新所有这些服务的 tad 描述文件,这是一个巨大的工作量。 高镜像分发成本:每个微服务都需要打包成镜像,然后分发到私有化客户的服务器上。所有微服务的镜像总大小已经超过了 10GB,给分发带来了很大的挑战。
modules:
- name: monolith-module1
merged_servers:
- name: microserver1
...
- name: microserver2
...
- name: monolith-module2
merged_servers:
- name: microserver3
...
- name: microserver4
...
3.1 挑战一:各式各样的框架
3.2 挑战二:大相径庭的配置
plugin:
config:
app:
providers:
serverA:
app.yaml:
foo: bar
foz: baz
plugin:
config:
app:
providers:
serverA:
app.yaml:
foo: bar
foz: baz
serverB:
app.yaml:
zoo: bar
zoz: baz
...
plugin:
type-foo:
name-bar:
key1: value1
key2: value2
plugin:
type-foo:
name-bar:
service1:
key1: value1
key2: value2
service2:
key1: value2
key2: value1
...
3.3 挑战三:随意修改的状态
3.4 挑战四:隐秘角落的臭虫
func Register(s *server.Server) {
someserverpb.RegisterSomeServerSomeService(s,newSomeServiceImpl())
}
首先明确问题。例如,在上述示例中,我需要确认 /foo/bar 这个 CGI 访问时是否真的会返回404,以及这是否是由服务合并所导致的后果。因此,我需要在原始微服务环境下验证这个 CGI 访问是否正常,而在单体服务中,它是否会返回404。 明确问题后,我们可以去掉一半的服务,然后观察是否正常。如果表现依旧,那么就继续去掉一半的服务。如果表现恢复正常,我们就增加当前1/2数量的服务。这样,很快就可以定位到究竟是合并哪个服务导致了这个问题。这个步骤类似于二分查找法,但由于它用于定位问题,因此我称之为“二分定位法”。
3.5 挑战五:花样百出的变更
// Code generated by backend/tools/monolith, DO NOT EDIT.
// Package service rpc入口层。
package service
import (
{{- range .MergedServers}}
{{.}}service "docx/backend/application/{{.}}/service"
{{- end}}
"git.code.oa.com/trpc-go/trpc-go/server"
)
// Register 注册 pb service 实现。
func Register(s *server.Server) {
{{- range .MergedServers}}
{{.}}service.Register(s)
{{- end}}
}
参考阅读:
本文由高可用架构转载。技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿